-
Notifications
You must be signed in to change notification settings - Fork 950
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for "none python" parameters used in the put_object method #108
base: master
Are you sure you want to change the base?
Conversation
Anyone had a look at this yet? |
I don't have any significant objections to the content of this pull request, and I am glad that you took pains to make it backwards-compatible. However, I wonder whether Facebook's increasing use of colons in their API methods means that it makes sense to just replace all methods that use kwargs with dictionaries. This would break compatibility in a major way, but would make the code simpler and more future-proof. |
That is true and would make sense. The only thing is that I haven't seen it On 8 January 2014 17:43, Martey Dodoo [email protected] wrote:
|
I think there at least one other place, but it is possible that I am misremembering. |
Made any decision regarding this yet? I think it would be great if it was merged, since it doesn't break backwards compatibility and fixes the issue I'm having... 😃 |
I have added this to the 1.0.0 milestone, so I plan on dealing with this before the next release. I have not have a chance to look into whether this commit will be merged directly, or whether larger changes need to be made, though. |
Great stuff, let me know if there is anything I can do. |
+1 on this PR |
There are parameters available in the Facebook API that can not be represented by python arguments, for instance "fb:explicitly_shared" (https://developers.facebook.com/docs/opengraph/guides/explicit-sharing/). Therefore there is a need to make the put_object method more flexible. I suggest doing so by allowing a post_args dictionary as a method argument. Since there might be conflicts between the post_args dictionary and the kwargs, I've implemented it in such a way that the kwarg always will take precedence.